Control MQTT en vivo

tip

El control MQTT en vivo está destinado para control en vivo. Para enviar horarios con anticipación, consulte Control MQTT Programado en su lugar.

Esta guía le ayudará a configurar MQTT en su SmartgridOne Controller para controlar y monitorear de forma remota instalaciones de baterías y paneles solares.

Qué necesita

1. SmartgridOne Controller con conectividad a internet.
2. Credenciales MQTT: Esto se puede solicitar enviando un correo electrónico a support@eniris.be.
3. Entorno de desarrollo Python (o cualquier otro cliente MQTT). Esta guía utiliza un ejemplo básico escrito en Python para ayudarle a comenzar con MQTT y el envío de comandos. Recomendamos usar Python por su facilidad de uso, pero se admite cualquier otro cliente MQTT.

Información adicional

MQTT es un protocolo de comunicación rápido a través de internet. Es un sistema de mensajes de publicación/suscripción, que permite una conexión directa entre su máquina y el SmartgridOne Controller. Sus activos se clasifican en grupos de solar, batería, EV y HVAC.

Configuración inicial (Punto de partida para nuevos usuarios)

Tengo un SmartgridOne Controller que me gustaría configurar para Control Remoto MQTT.

1. Verifique su red

Asegúrese de que su red permita el tráfico de red mqtt a través del puerto 1883. Puede hacer esto utilizando el comando:

nc -zv mqtt.eniris.be 1883

Cuando este comando no esté disponible, puede descargar y ejecutar este código python.

Cuando tenga dudas, consulte a su ingeniero de red o use temporalmente el hotspot 4G/5G de su teléfono cuando ocurran errores de conexión.

nota

Cuando el puerto 1883 no es accesible desde su red, ofrecemos una copia de seguridad en el puerto 80. Esto se puede configurar en su cliente MQTT en un paso posterior de este manual.

2. Agregue sus dispositivos

Inicie sesión en la interfaz de puesta en marcha y asegúrese de que los dispositivos estén agregados al SmartgridOne Controller.

3. Agregue la señal externa MQTT

4. Habilite la señal remota MQTT

El campo 'VPP ID' debe dejarse vacío.

El tiempo de espera del mecanismo de respaldo indica al SmartgridOne Controller cuánto tiempo debe esperar nuevos comandos. Cuando el SmartgridOne Controller deja de recibir comandos, automáticamente adopta la estrategia predeterminada después de este tiempo de espera.

Después, seleccione todos los dispositivos que desea incluir en el Control Remoto MQTT.

5. La señal remota ha sido agregada

La interfaz de Control Remoto MQTT ha sido activada en el SmartgridOne Controller.

Ahora estamos listos para enviar algunos comandos básicos utilizando un ejemplo simple. La columna de Estado le indica si algún comando está activo.

Script de demostración en Python

Un buen punto de partida sería probar su integración recién configurada con un ejemplo simple.

Este código de prueba realiza un trabajo simple de enviar continuamente los siguientes comandos:

• Batería: Cargar a 5 kW
• Solar: Establecer potencia en 0 kW

El SmartgridOne Controller responde continuamente con un mensaje de 'retroalimentación' que contiene los valores de potencia de red y activos observados. Esta función también se incluye en este ejemplo.

Por favor, descargue el archivo a continuación en su IDE de Python preferido. Rellene su número de serie y credenciales MQTT y ejecute el script:

Cuando lo anterior sea exitoso, puede continuar enviando otros tipos de comandos. Todos los comandos están descritos en nuestra Documentación de Control Remoto MQTT.

Documentación MQTT para Enviar Comandos

Esta sección detalla el formato de mensajería MQTT y los requisitos de carga útil para controlar de forma remota las políticas de energía en dispositivos dentro de la red del SmartgridOne Controller.

Tema MQTT

El tema MQTT utilizado para enviar comandos está estructurado como sigue:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Donde 'controller SN' debe ser reemplazado por el número de serie real del SmartgridOne Controller que desea controlar.

Estructura de Carga Útil MQTT

Los comandos se envían como cargas útiles JSON. La estructura de la carga útil está diseñada para especificar varias políticas de gestión de energía y puntos de ajuste para diferentes componentes del sistema de red inteligente. Aquí está el esquema de la carga útil con descripciones detalladas de los campos:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

Descripción de los campos

tip

Varios tipos de dispositivos (p. ej., baterías + solar) pueden ser controlados al mismo tiempo.

• extraTags (Objeto):
  • nodeId (Cadena): Un identificador único para el nodo dentro de la red del SmartgridOne Controller. Esto es igual a su número de serie, seguido de '_site_0' para la mayoría de los dispositivos SmartgridOne Controller.
• time (Entero): Marca de tiempo Unix en segundos que indica el momento en que se envía el mensaje.
• fields (Objeto):
  • <Component>_policy (Cadena): Tipo de política para el componente. Es opcional y si no se especifica, el sistema revertirá a la configuración predeterminada del SmartgridOne Controller.
  • <Component>_power_setpoint_w (Flotante): Punto de ajuste de potencia deseado en vatios para el componente. Esto es opcional y solo relevante si se especifica una política correspondiente.

Componentes y Políticas

info

Los activos del mismo tipo (por ejemplo, dos baterías) se combinarán como un componente. Por ejemplo, cuando se instalan dos baterías de 5 kWh, se tratará como una batería de 10 kWh.

Cada componente en el objeto fields puede incluir una política y un punto de ajuste de potencia. Los siguientes componentes pueden ser controlados:

• solar_policy y solar_power_setpoint_w:

  • Controla la política de generación de energía solar y el punto de ajuste. Políticas soportadas:
    • Política de punto de ajuste: Establece la máxima potencia producida por todas las instalaciones solares conectadas combinadas. El campo solar_power_setpoint_w debe ser establecido en el límite de potencia de producción en vatios.
    • Política de restricción de inyección: Producir a plena potencia, siguiendo los límites actuales de la red.
    • Política de costos: Habilita la minimización de costos de precios a un día de antelación (mercado EPEX Spot) en la producción solar. Cuando ocurren precios de inyección negativos, limitamos la producción a nuestro consumo. Cuando tanto el precio de retirada como el de inyección son negativos, apagamos todas las instalaciones solares. El campo solar_power_setpoint_w es ignorado.
    • Política de apagado: Desactiva toda interacción para todos los activos solares. Advertencia: los límites no se protegen en este modo. El campo solar_power_setpoint_w es ignorado.

• storage_policy y storage_power_setpoint_w:

• Controla la política del sistema de almacenamiento de energía y la tasa de descarga o carga de energía.

  • Punto de ajuste de la política: Establece la potencia total de carga (punto de ajuste positivo) o la potencia de descarga (punto de ajuste negativo) para el grupo de baterías. Cuando se conectan múltiples baterías, el punto de ajuste se divide por la potencia de carga/descarga disponible para estresar igualmente las baterías. El campo storage_power_setpoint_w se establece en la potencia de batería deseada.
  • Costo de la política: Habilita la optimización de costos de precios a un día (mercado EPEX Spot) en las baterías, cargándolas durante las horas baratas y utilizando la energía en las horas caras. El campo storage_power_setpoint_w se ignora.
  • Política de autoconsumo: Habilita un algoritmo de autoconsumo simple en las baterías. La producción solar excedente se almacena en la batería durante el día, y cuando el sol se oculta, se toma energía de la batería. El campo storage_power_setpoint_w se ignora.
  • Política desactivada: Deshabilita toda interacción para todos los activos de la batería. Advertencia: los límites no están siendo resguardados en este modo. El campo storage_power_setpoint_w se ignora.

• heat_pump_policy:

  • Activa/desactiva sistemas de bombas de calor. Los tiempos mínimos y máximos de encendido siempre se respetarán.
  • Costo de la política: Habilita la optimización de costos de precios a un día (mercado EPEX Spot) en las bombas de calor. El algoritmo de precios dinámicos local decide los mejores períodos de encendido.
  • Política de autoconsumo: Enciende las bombas de calor si se produce un excedente de energía solar.
  • Política de apagado: Apaga las bombas de calor.
  • Política de encendido: Enciende las bombas de calor.

• switched_load_policy:

  • Activa/desactiva sistemas controlados por relés. Esto podría ser el relé incorporado o relés conectados a la red.
  • Costo de la política: Habilita la optimización de costos de precios a un día (mercado EPEX Spot) en el relé.
  • Política de autoconsumo: Enciende el relé si se produce un excedente de energía solar.
  • Política de apagado.
  • Política de encendido.

• variable_power_load_policy y variable_power_load_power_setpoint_w:

  • Gestiona la política de consumo de energía de vehículos eléctricos y el punto de ajuste.
  • Punto de ajuste de la política: Establece la potencia total de carga para el grupo de vehículos eléctricos (EV). El campo variable_power_load_power_setpoint_w se establece en la potencia de carga deseada.
  • Costo de la política: Habilita la optimización de costos de precios a un día (mercado EPEX Spot) en las baterías, cargándolas durante las horas baratas. El campo variable_power_load_power_setpoint_w se ignora.
  • Política de autoconsumo: Habilita la carga si se produce un excedente de energía solar. El campo variable_power_load_power_setpoint_w se ignora.
  • Política desactivada: Deshabilita toda interacción para todos los activos de vehículos eléctricos. El campo variable_power_load_power_setpoint_w se ignora.

• site_policy y site_power_setpoint_w:

  • Gestiona los límites de exportación del sitio.
  • Política de exportación: Establece el límite de exportación para el sitio. El campo site_power_setpoint_w se establece en el límite de exportación.
  • Política predeterminada: Revierte el límite del sitio a la potencia de exportación predeterminada, establecida en la configuración del controlador.

Control de Dispositivos

Los dispositivos específicos también se pueden controlar, en lugar de grupos de dispositivos según sus tipos. El mensaje tiene una estructura idéntica:

• nodeId_policy y nodeId_power_setpoint_w

info

Cuando se envían dos comandos al mismo activo (por ejemplo, un comando específico de dispositivo a un inversor solar y un comando a todos los dispositivos solares), el método de control específico del dispositivo tendrá preferencia sobre el control por tipo de dispositivo.

Comportamiento de retroceso

Para cada componente, si no se especifica _policy y _power_setpoint_w, el sistema utilizará automáticamente la política de retroceso configurada en el SmartgridOne Controller. Esto asegura que cada dispositivo o grupo de dispositivos opere de manera segura y continúe funcionando incluso si no se proporcionan instrucciones específicas.

Si no se envía ningún comando en absoluto, después de 60 segundos (o el período de tiempo de espera configurado), se reactivarán las políticas predeterminadas para los activos.

Cancelar comandos existentes y volver a modos de control local

Un comando activo puede ser cancelado enviando un mensaje de comando de retroceso.

Comando de Retroceso

Un comando de retroceso cancelará el comando existente inmediatamente y el SmartgridOne Controller tomará el control de la instalación. La política ejecutada depende de lo que esté configurado en el SmartgridOne Controller Settings.

Esto también se puede utilizar en casos donde se utilice una señal de control secundaria, como un horario, como retroceso.

Ejemplos de mensajes:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "fallback",
    }
}

Comando Vacío

Un comando vacío se puede enviar en cualquier momento para recopilar información del sitio. Esto no cancelará el comando actual, y no sobrescribirá los comandos de señales de control secundarias con prioridades más bajas.

El comando vacío se estructura de la siguiente manera:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {}
}

Ejemplo de carga útil

A continuación se presenta un ejemplo de una carga útil para establecer varias políticas y puntos de ajuste:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

En este ejemplo, se establece que la energía solar genere hasta 5000 vatios, y el sistema de almacenamiento de energía se configura para cargar o descargar a una tasa de 5000 vatios, dependiendo del signo del valor del punto de ajuste. Si se omitieran la solar_policy o storage_policy, el dispositivo respectivo volvería a la configuración predeterminada determinada por el SmartgridOne Controller.

Documentación MQTT para recibir comentarios

Esta sección describe la estructura y el contenido de los mensajes de retroalimentación enviados por el SmartgridOne Controller a través de MQTT. Estos mensajes se publican en el tema standard1/outbound/remoteControlMetrics/feedback/<Controller SN> después de que un comando ha sido procesado.

Tema de Retroalimentación MQTT

El tema de retroalimentación MQTT está estructurado de la siguiente manera:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Donde <Controller SN> debe ser reemplazado por el número de serie del SmartgridOne Controller que está enviando la retroalimentación.

Estructura de la Carga Útil de Retroalimentación MQTT

nota

Todos los activos están agrupados por su tipo. Esto significa que dos instalaciones solares individuales de 3 kW se tratarán como un activo de 6 kW.

Los mensajes de retroalimentación están formateados como cargas útiles JSON. Estas cargas útiles proporcionan una retroalimentación detallada sobre el estado del sistema después de aplicar los comandos de los puntos de ajuste, considerando los límites de la red/dispositivo. A continuación se muestra la estructura de la carga útil de retroalimentación con descripciones de sus campos:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Potencia Activa de la Red en Vatios>,
                "today_imported_energy_Wh": <Energía Importada de la Red en Vatios-hora>,
                "today_exported_energy_Wh": <Energía Exportada a la Red en Vatios-hora>,
                "import_limit_W": <Límite de Importación de la Red en Vatios>,
                "export_limit_W": <Límite de Exportación de la Red en Vatios>,
            },
            "vpp_id": "<Identificador de Planta de Energía Virtual>",
            "storage": {
                "energy_stored_Wh": <Energía Almacenada en Vatios-hora>,
                "energy_capacity_Wh": <Capacidad Total de Energía en Vatios-hora>,
                "mean_soc_perc": <Porcentaje Medio de Estado de Carga>,
                "active_power_W": <Potencia Activa en Vatios>,
                "executed_power_W": <Punto de Ajuste de Potencia Enviado a Dispositivos en Vatios>,
                "executed_policy": <Política Ejecutada por el Controlador>,
                "max_charge_power_W": <Potencia Máxima de Carga en Vatios>,
                "max_discharge_power_W": <Potencia Máxima de Descarga en Vatios>,
                "today_charged_Wh": <Energía Cargada Hoy en Vatios-hora>,
                "today_discharged_Wh": <Energía Descargada Hoy en Vatios-hora>,
                "nr_devices": <Número de Dispositivos de Almacenamiento Controlados Instalados>
            },
            "solar": {
                "active_power_W": <Potencia Activa Solar en Vatios>,
                "executed_power_W": <Punto de Ajuste de Potencia Enviado a Dispositivos en Vatios>,
                "executed_policy": <Política Ejecutada por el Controlador>,
                "capacity_W": <Capacidad Solar en Vatios>,
                "today_energy_Wh": <Energía Producida Hoy en Vatios-hora>,
                "nr_devices": <Número de Dispositivos Solares Controlados Instalados>
            },
            "heat_pump": {
                "executed_policy": <Política Ejecutada por el Controlador>,
                "operation_modes": <Modos de Operación de la Bomba de Calor>,
                "executed_power_W": <Punto de Ajuste de Potencia Enviado a Dispositivos en Vatios>,
                "nr_devices": <Número de Dispositivos de Bomba de Calor Controlados Instalados>
            },
            "switched_load": {
                "executed_policy": <Política Ejecutada por el Controlador>,
                "devices_on": <Número de Dispositivos Encendidos>,
                "devices_off": <Número de Dispositivos Apagados>,
                "executed_power_W": <Punto de Ajuste de Potencia Enviado a Dispositivos en Vatios>,
                "nr_devices": <Número de Dispositivos de Carga Switch Controlados Instalados>  
            },
            "variable_load": {
                "executed_policy": <Política Ejecutada por el Controlador>,
                "executed_power_W": <Punto de Ajuste de Potencia Enviado a Dispositivos en Vatios>,
                "active_power_W": <Potencia del dispositivo en Vatios>,
                "ev_requiring_charge": <¿El vehículo eléctrico requiere carga?>,
                "currentL1_A": <Corriente del dispositivo en fase 1 en Amperios>,
                "currentL2_A": <Corriente del dispositivo en fase 2 en Amperios>,
                "currentL3_A": <Corriente del dispositivo en fase 3 en Amperios>,
                "executed_current_A": <Punto de Ajuste de Corriente Enviado a Dispositivos en Amperios>,
                "today_charged_Wh": <Energía Cargada Hoy en Vatios-hora>,
                "today_discharged_Wh": <Energía Descargada Hoy en Vatios-hora>,
                "total_charged_Wh": <Total de Energía Cargada en Vatios-hora>,
                "total_discharged_Wh": <Total de Energía Descargada en Vatios-hora>,
                "min_charge_current_A": <Carga Mínima en Amperios>,
                "max_charge_current_A": <Carga Máxima en Amperios>,
                "allow_zero_current": <¿El Cargador Soporta Pausar?>,
            }
        },
        "response_code": <Código de Respuesta>
    },
    "fields": {},
    "requestTime": "<Marca de Tiempo Unix>",
    "time": "<Marca de Tiempo Unix>",
    "siteNodeId": "<Controlador SN>_site_0"
}
            - executed_policy (Str): Las políticas que se han aplicado a los controlables,
            - executed_power_W (Float): La suma de la potencia total solicitada de los activos, enviada por nuestro algoritmo de control.
            - active_power_W (Float): Representa la potencia activa actual en la red en vatios.
            - ev_requiring_charge (Bool): ¿El EV requiere carga? (¿Está un auto conectado?).
            - currentL1_A (Float): Corriente del dispositivo en la fase 1 en amperios.
            - currentL2_A (Float): Corriente del dispositivo en la fase 2 en amperios.
            - currentL3_A (Float): Corriente del dispositivo en la fase 3 en amperios.
            - executed_current_A (Float): La suma de la corriente total solicitada de los activos, enviada por nuestro algoritmo de control.
            - today_charged_Wh (Float): La energía cargada en el(s) activo(s) de cargador de EV hoy. Nota: Hoy se da en hora UTC.
            - today_discharged_Wh (Float): La energía descargada del(s) activo(s) de cargador de EV hoy. Nota: Hoy se da en hora UTC.
            - total_charged_Wh (Float): La energía total cargada en el(s) activo(s) de cargador de EV.
            - total_discharged_Wh (Float): La energía total descargada del(s) activo(s) de cargador de EV.
            - min_charge_current_A (Float): Corriente mínima a la que se puede cargar el EV.
            - max_charge_current_A (Float): Corriente máxima a la que se puede cargar el EV.
            - allow_zero_current (Bool): ¿El cargador de EV permite pausar?
        - nodeId (Object):
            - Si se incluye un nodeId en el comando, la retroalimentación contendrá el estado correspondiente del dispositivo.
    - response_code (Int):
        - Indica el estado de la operación. Un response_code de 0 generalmente significa éxito, mientras que otros valores pueden indicar diferentes tipos de errores o información de estado (estos deben detallarse en una referencia separada).

### Ejemplo de Carga de Retroalimentación
Aquí hay un ejemplo de un mensaje de retroalimentación tras un comando para establecer varios puntos de ajuste de potencia:

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Image 1" maxWidth="450px" />

Esta retroalimentación demuestra el estado operativo actual del sistema tras la ejecución de los puntos de ajuste, indicando los efectos en la generación solar, el almacenamiento y la interacción general con la red.

## Versiones MQTT Soportadas y Comportamiento en Temas No Autorizados
Al utilizar MQTT, es importante considerar las diferencias en las especificaciones entre las versiones 3.1, 3.1.1 y 5.0, particularmente en lo que respecta al comportamiento del broker cuando los clientes publican en temas no autorizados.

De acuerdo con la especificación MQTT 3.1.1 (ver OASIS MQTT 3.1.1 Specification, sección MQTT-3.3.5-2), un broker debe terminar la conexión tan pronto como un cliente envía un PUBLISH a un tema para el cual no tiene permiso. Este comportamiento puede llevar a desconexiones inesperadas para los clientes que intentan publicar en temas mal configurados o no autorizados.

En MQTT 3.1, este requisito no está presente. Cuando un cliente publica en un tema no autorizado bajo esta versión, el broker generalmente ignora el mensaje (eliminación silenciosa) sin terminar la conexión. Esto hace que MQTT 3.1, en algunos casos, sea más adecuado cuando la robustez frente a errores de configuración o permisos temporalmente faltantes es más importante que la estricta aplicación de seguridad.

Aunque MQTT 5.0 introduce la capacidad de trabajar con códigos de razón (como PUBACK con un motivo de rechazo), esto requiere soporte tanto en el lado del cliente como en el del servidor. La migración a MQTT 5.0, por lo tanto, implica un esfuerzo adicional de implementación.

__Consecuencias de Ignorar la Compatibilidad:__
Si un cliente se conecta utilizando MQTT 3.1.1 e intenta publicar mensajes en temas no autorizados, el broker finalizará abruptamente la sesión. Esto puede llevar a inestabilidad, pérdida de conectividad o aumento de carga debido a los intentos repetidos de reconexión.

__Enfoque Recomendado:__
Para sistemas donde los clientes pueden (temporalmente) intentar publicar en temas no autorizados, o donde el manejo de errores no se implementa estrictamente, recomendamos usar MQTT 3.1. Esto asegura conexiones más estables y evita desconexiones no intencionadas durante la ejecución.